home *** CD-ROM | disk | FTP | other *** search
/ Ham Radio 2000 / Ham Radio 2000.iso / ham2000 / satellit / pacdoc / dataspec.doc < prev    next >
Text File  |  1990-09-05  |  5KB  |  126 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.                     PACSAT Data Specification Standards
  7.  
  8.                     
  9.  
  10.           
  11.  
  12.                            Harold E. Price, NK6K
  13.                              Jeff Ward, G0/K8KA
  14.  
  15.                                 
  16.  
  17.                                   ABSTRACT
  18.           
  19.  
  20.  
  21.      This  document provides a standard way of describing  PACSAT  data 
  22.      formats  in specifications, and provides certain  assumptions  for 
  23.      implementors.
  24.  
  25.  
  26.  
  27.  
  28. Purpose
  29.  
  30. This document describes the standard format for PACSAT data.
  31.  
  32.  
  33. Background
  34.  
  35. This standard is based on the following assumptions:
  36.  
  37. 1)  The spacecraft are the critical resources in the PACSAT/groundstation net-
  38. work.  If a particular data representation can conserve memory space and CPU 
  39. cycles in the spacecraft, all other items being equal, the representation that 
  40. favors the spacecraft should take precedence.
  41.  
  42. 2) The UoSAT and the AMSAT-NA PACSAT hardware are based on an Intel 80186-
  43. compatible device.  Therefore, all internal multi-byte numeric data is stored 
  44. with the least-significant byte in low-order memory.
  45.  
  46. 3) The UoSAT and the AMSAT-NA PACSAT software is largely based on the Micro-
  47. soft C programming language.
  48.  
  49. 4) The UoSAT and the AMSAT-NA PACSAT software development systems are based on 
  50. IBM PCs or compatibles.
  51.  
  52.  
  53. Discussion
  54.  
  55. The primary decision to be made in PACSAT data formats is "big endian" (BE) 
  56. vs. "little endian" (LE).  Most network standards are defined as BE, meaning 
  57. the Most Significant Byte (MSB) of multi-byte data appears in low order ad-
  58. dress space, and the Least Significant Byte (LSB) appear in high order memory.  
  59. The UoSAT and Microsat spacecraft all use Intel 80186 or compatible CPUs, 
  60. which store data with the LSB first, and are LE.
  61.  
  62. Multi-byte data appears in many places in PACSAT data, including the file 
  63. headers and the control structures of the broadcast and FTL0 protocols.  If 
  64. these protocols were BE, the spacecraft software would need to swap byte order 
  65. in several places.  Whether done as in-line code or as function calls, these 
  66. conversions use both CPU cycles and code space.  It is clear that a native 
  67. data representation will result in a more efficient utilization of the space-
  68. craft CPU, and that the data format conversions, if any, should be done on the 
  69. ground.  Experimentation was done showing that avoiding byte swapping on the 
  70. spacecraft resulted in significant space savings.
  71.  
  72. This will not affect the actual high-level software code, as prudent program-
  73. mers who wish to write transportable code that is applicable to BE and LE 
  74. hosts will use macro calls to swap the byte order when moving data from an 
  75. external source to local variables.  By using the somewhat less common LE in 
  76. the protocol specification, the macro will be active on BE systems when it 
  77. would normally be active on LE systems.  In any case, the macros would still 
  78. be present in the source file.
  79.  
  80. For example, 
  81.  
  82. fnum = NETSWAP32(broadcast_head.fnum);
  83.  
  84. would be the line of code to read in the file number from a broadcast protocol 
  85. frame.  This code will be the same no matter which order the protocol required 
  86. the 4-byte integer field to be in.
  87.  
  88. Taking these assumptions into account, the standard to be used when defining 
  89. data exchange formats between PACSAT and a ground station are as defined 
  90. below.
  91.  
  92.  
  93. Intended Applicability
  94.  
  95. This document is primarily intended to apply to shared file formats, such as 
  96. the standard PACSAT File Header; and to PACSAT specific protocols such as the 
  97. PACSAT Broadcast Protocol.  It is not meant to infer that existing protocols, 
  98. such as IP, are to have integers byte-swapped when transmitted to a PACSAT.
  99.  
  100.  
  101. PACSAT Data Structure Specification Standard
  102.  
  103. 1)  All structure definitions in PACSAT standards documents should provide C 
  104. structures wherever possible to describe data formats.  
  105.  
  106. 2)  All structures are assumed to be packed; do not assume slack bytes are  
  107. provided to align words and doublewords.
  108.  
  109. 3)  All multi-byte numeric data is assumed to be stored and transmitted with 
  110. the Least Significant Byte first.
  111.  
  112. 4)  Where it is necessary to number bits, the least significant bit is zero.
  113.  
  114. 5)  The standard method for referring to hexadecimal constants will be the C 
  115. standard 0xhh.
  116.  
  117. 6)  The assumed length of an unsigned or int type is 16 bits.
  118.  
  119. 7)  The "left" end of a string is stored and transmitted first.
  120.  
  121. 8)  "ASCII" characters are the printable ASCII characters 0x20-0x7f.
  122.  
  123. 9)  Times are represented by the UNIX 4-byte unsigned integer counting the 
  124. number of seconds since 0000 UTC 1 January, 1970.
  125. 
  126.